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HYBRID DATA TRANSPORT SCHEME OVER OPTICAL NETWORKS 
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incorporated by reference in its entirety. 
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O ^SQifob , filed March 10, 2000 KAttornoy Docket Nu. 0325.0031 - 7 4 
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concurrently fatt&xTTey^&&cfc^^ and U.S. Serial No. 

O 0jljffL f filed concurrently (ffc&rfrtey^^ , 
which are each hereby incorporated by reference in their entirety. 



a_f5 Field of the Invention 

The present invention relates to a method and/or 
architecture for hybrid data transportation generally and, more 
particularly, to sending a mix of different data types over a fiber 
optic network- running SONET/SDH framing. 
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Background of the Invention 

Long distance and metropolitan area network (MAN) 
communications rely on short-haul and long haul fiber optic 
networks to transport data and telephony traffic. One conventional 
way to transmit data in fiber networks is through a Synchronous 
Optical Network/ Synchronous Digital Hierarchy (SONET/SDH) protocol. 
In a SONET/SDH network, data travels in fixed size envelopes that 
repeat every 125 microseconds. With this synchronous fixed-length- 
framing, every byte (e.g., 8 bits of data) inside a SONET/SDH frame 
represents a 64 Kbps (64000 bits/sec) channel. The 64 Kbps channel 
has the same rate as supported by current telephone channels (also 
called DS0 channels) . 

SONET was designed to efficiently carry telephony 
Plesiochronous Digital Hierarchy (PDH) channels such as T1/T3 . This 
was easily achieved by dividing the payload area in fixed slots 
called virtual tributaries (VT) . These virtual tributaries are then 
grouped together to form higher-rate channels. These fixed slots 
are efficient for carrying fixed-bandwidth telephony channels 
because any one or more channels can be added or removed from a 
bundle without processing an entire payload of channels. Because 
SONET frames repeat at fixed intervals, these virtual tributaries 
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have fixed locations and time intervals, and it is easy to extract 
T1/T3 or fractions of Tl without processing the entire SONET 
payload. 

With growing volume in data traffic, however, SONET/SDH 
networks must now carry a significantly large number of data 
packets - such as ATM (Asynchronous Transfer Mode - 53 bytes each) 
and IP (Internet Protocol - variable-size packets) in addition to 
traditional T1/T3 channels. The synchronous framing structure of 
SONET/SDH that is quite efficient for carrying T1/T3 channels is 
not able to carry both fixed-bandwidth and variable -bandwidth 
channels in an optimum way. 

SONET/SDH has an inefficient utilization of fiber 
bandwidth for data packets. For data transport, some of the 
virtual tributaries that are created for transporting fixed- 
bandwidth Tl traffic while others are used for transporting packet 
data packets such as ATM and IP. Since an individual virtual 
tributary has a limited bandwidth, extra mechanisms have to be used 
for sending data packets of higher bandwidth using virtual 
tributaries . 

In one technique, a 10Mbps data packet channel, for 
example, is inverse-multiplexed into smaller bandwidth streams and 
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then sent on many virtual tributaries. At the other end, these 
streams are integrated to reconstruct the full 10Mbps channel. In 
another method, many of the virtual tributaries are concatenated 
using hardware to create a higher-bandwidth virtual tributary for 
transmitting the high-bandwidth data packet. 

SONET/SDH lacks of support for data mixing. A SONET 
fiber link carrying frames containing ATM cells cannot carry POS, 
because ATM cells frequently carry QoS-sensitive data such as CES 
(Circuit Emulation Service) or multimedia traffic. Introduction of 
SONET frames containing POS will cause significant delays (e.g., 
125 jlS for each POS frame inserted in the link) . 

In each of these methods, a unique Path Signal Label 
(PSL) value in the POH (Path Over-Head) field of^ SONET frame 
identifies the type of data transmission inside the payload. The 
payload area is also referred to as SPE (Synchronous Payload 

ik 

Envelope) . Because a PSL value identifies contents of, entire SONET 

A 

payload envelope, only one type of transmission can be supported at 
a time in a SONET frame. 

One method for data transmission is to use the entire 
SONET SPE for data packets. The SONET payload area is filled with 
IP packets using Packet -over- SONET (POS) packets. POS packets are 
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packets^ by 0x7E (Hexadecimal) at both ends of a packet, with a 
framing using PPP ( Point -to-Point Protocol) . Many packets can be 
put inside a single SONET SPE. This method can only support 
variable- length packet protocol such as IP. A SONET fiber 
containing these packets cannot transport T1/T3 channels or real- 
time streams using ATM cells. The reason for this limitation is 
that each SONET SPE containing IP packets, for example, introduces 
a delay of 12 5 microseconds. Such a delay is not acceptable for 
T1/T3 circuits or real-time streams using ATM cells. 



4P Another method for data transmission is to use the entire 

SONET SPE for ATM cells. In this case, SONET SPE is filled with 
ATM Cells. ATM cells are delimited by their fixed length, and are 
tracked by doing a hunt for their header checksum byte. Services 
such as Tl, Frame Relay, Ethernet, etc. are transported over ATM 

■a 

JSS. 

JfS using standard protocols. This requires complex implementations in 

hardware and incorporation of ATM service interworking at each 

service boundary. 

Another method for data transmission is to use the 

virtual tributaries (VT) for data packets and ATM cells. In this 
20 method, a SONET SPE is partitioned in many fixed-bandwidth slots 

called virtual tributaries (VT) . For data transport, some of these 
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virtual tributaries may contain T1/T3 type of fixed -bandwidth 
traffic while others are used for transporting packet data packets 
such as ATM and IP. 

Since an individual virtual tributary has a limited 
bandwidth, extra mechanisms have to be used for sending data 
packets of higher bandwidth using virtual tributaries. In one 
technique, a 10Mbps data packet channel, for example, is inverse - 
multiplexed into smaller bandwidth streams and then sent on many 
virtual tributaries. At the other end, these streams are 
integrated to reconstruct the full 10Mbps channel. In another 
method, many of the virtual tributaries are concatenated using 
hardware to create a higher-bandwidth virtual tributary for 
transmitting the high-bandwidth data packet. 

Each of these methods uses a fixed-bandwidth channel or 
a set of channels for transmitting network data packets. In each 
method, bandwidth capacity of the fiber is poorly utilized since 
network data packets are bursty in nature and average bandwidth 
utilization is quite low. 

Referring to FIG. 1, examples of various data types are 
shown. A set of time-division-multiplexed (TDM) packets 12a-12n, 
a set of ATM packets 14a- 14n and a set of POS packets 16a- 16n are 
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shown in connection with a SONET fiber line 18. In a SONET 

network, only one type of data can be transferred at a time. The 

data is identified by a unique PSL (path signal label) byte value 

inside a Path Over-Head (POH) of the TDM packets 12a- 12n, ATM 

A 

packets 14a-14n, the POS packets 16a-16n, of PDH traffic. The nodes 
at different points in the SONET fiber line 18 have different types 
of data to send on the network. 

Referring to FIG. 2, an example of a system 20 
illustrating problems in transmitting higher bandwidth data packets 
with fixed bandwidth slots is shown. Transmission of fixed and 
variable -bandwidth packets in SONET/SDH frames is shown. SONET/SDH 
was developed for efficiently transporting telephony signals over 
long links. In order to support timing of the smallest telephony 
components DSO (e.g. , 64Kbps) , SONET/SDH frames are generated using 
fixed length packets repeated at intervals of 125uS. 

At such a transfer rate, each byte of a SONET/SDH frame 
represents a basic telephony channel, often represented as DSO. A 
number of such bytes are reserved to form higher- order PDH signals 
(such as Tl) which use 28 DSO channels. One such method for 
supporting telephony channels is by dividing the payload into a 
number of virtual tributaries (VT) . 
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To achieve precise timing, PDH bytes must begin at the 
same offset inside a SONET SPE 22a-22n. If data packets are 
transmitted along with the PDH channels, the data must be sent in 
the fixed length slots. Allocation of PDH channels at different 
locations inside the SONET SPE 22a-22n creates fragments of unused 
bytes all over the SPE. If the slots B/D/F/G/H/I are used for 
variable- length data packets, the slots cannot be fully used 
because the fixed bandwidth slots, such as C and E, do not allow 
the packets to continue without fragmenting while crossiing slot 
boundaries . 

Two conventional approaches have been used to accommodate 
high bandwidth signals along with low bandwidth signals. A first 
conventional approach is virtual concatenation. A second 
conventional approach is inverse multiplexing. 

Referring to FIG. 3, an example of a conventional virtual 

concatenation approach is shown. To transport fixed bandwidth 

traffic (e.g., T1/T3) , the SONET SPE payload area is divided into 

fixed timeslots (i.e., virtual tributaries). An example of a 

virtual taeiburarre^ is the standard VT1 . 5 . A VT1 . 5 can carry 
A 

1.5Mbps of information for each tributary, which is equal to a Tl 
channel . 
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Allocation of bandwidth for LAN data (such as 3r 9M/l6 e ftfr 
Ethernet) using a SONET fiber network and VT becomes difficult. 
For example, one has to either dedicate an entire STS-1 (51Mbps) , 
or use several VT channels with inverse multiplexing (to be 
described in more detail in connection with FIG. 3) . 

Virtual concatenation combines several VT channels into 
bigger virtual pipes to carry higher bandwidth traffic. With such 
a protocol, some virtual tributaries can carry T1/T3 data as usual 
while others are concatenated for transport of higher bandwidth 
data traffic such as 10/100Mbps . When many VT channels are 
concatenated, a fatter pipe of a higher bandwidth may be generated 
that can carry the entire bandwidth of a LAN. As a result, 
splitting a higher bandwidth into smaller VT channels and having to 
regroup them to get the LAN traffic can be avoided. However, 
virtual concatenation has one or more of the following 
disadvantages : 

(i) virtual concatenation allocates a fixed bandwidth for 
LAN, but cannot dynamically adjust bandwidth usage on a packet -by- 
packet basis; 

(ii) bursty LAN traffic bandwidth usage is typically 
quite low, which can result in significant waste when used over a 
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fixed bandwidth pipe (e.g., the average use of a 10Mbps link is 20% 
and, if an entire STS-1 is used, the efficiency becomes about 4%) ; 
and/or 

(iii) while some virtual pipe may be overloaded with 
traffic others may be underused (i.e., virtual concatenation cannot 
dynamically adjust network loads on different channels) . 

Referring to FIG. 4, an example of the inverse 
multiplexing approach for transmitting higher bandwidth channels is 
shown. Inverse multiplexing is similar to the virtual 

concatenation. However, different SONET virtual tributaries (e.g., 
L I NK# 1 - L I NK#N ) are not concatenated but are used as separate 
conduits of data transfer. 

Data from a high bandwidth pipe, such as a 10Mbps 
Ethernet LAN, can be sent over the multiple VT1 . 5 tributaries 
L I NK# 1 - L I NK#N using inverse multiplexing. The data is later 
recovered using standard inverse multiplexing protocols. Inverse 
multiplexing suffers from the same problems of bandwidth 
maximization as the virtual concatenation approach. In particular, 
bandwidth needs to be reserved in advance and all of the available 
bandwidth is not usable. 
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In particular, inverse multiplexing suffers from one or 
more of the following disadvantages: 

(i) inverse multiplexing allocates a fixed bandwidth for 
LAN, but cannot dynamically adjust bandwidth usage on a packet -by- 
packet basis; and/or 

(ii) bursty LAN traffic bandwidth usage is typically 
quite low, resulting in a significant waste when used over a fixed 
bandwidth pipe (e.g., if the average use of a 10Mbps link is 20% 
and if an entire STS-1 is used, then the efficiency becomes about 
4%) . 

Similar to virtual concatenation, while one VT (e.g., 
LINK#1) may be overloaded with traffic, other VTs (e.g., LINK#2- 
LINK#N) may be underutilized. Therefore, the bandwidth cannot be 
dynamically adjusted on different VT channels. 

Referring to FIG. 5, an example of ATM VP multiplexing 
is shown. ATM VP multiplexing provides another conventional 
approach to attempt to fully utilize SONET bandwidth. ATM VP 
multiplexing fills the payload area with ATM cells, where packets 
are encoded in ATM cells and then placed inside a SONET SPE. 
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ATM Circuit Emulation Service (CES) is normally used for 
carrying PDH traffic such as Tl . Data packets are transmitted 
using Multiprotocol -over-ATM encapsulation methods. 

ATM VP multiplexing suffers from one or more of the 
5 following disadvantages: 

(i) operations, administration and maintenance (OAM) 
operations of an ATM network are different from that of a SONET 
network, and management of the two networks can become difficult; 
CI (ii) ATM network routing and switch-to-switch signaling 

Ji:0 of data paths are different from IP network routes, resulting in 
%1 network operational complexity; and/or 

f\ (iii) a high percentage of network traffic consists of IP 

p packets with small packet sizes of around 40 bytes. With IP over 
flj ATM (e.g., rfc2684 - Multiprotocol Encapsulation over ATM AAL5) , 
flte payload size slightly exceeds what can fit inside a single ATM 
cell. Such an excess results in transmission of two ATM cells, 
with the second cell that is mostly ATM overhead and stuffing 
bytes. The transmission of two ATM cells, along with other ATM 
overhead, requires allocating extra SONET bandwidth for IP 
20 transport. 
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Referring to FIG. 2, various data transmissions are shown 

A 

in a SONET ring 30. Assume, for example, that a node A has ATM 
cells 14a-14n to transmit on the SONET ring 30. The SONET ring 30 
forms a SONET synchronous payload envelope (SPE) , sets the PSL 
value for ATM cells (in the POH) and sends the SONET frame down a 
link 32a-32n. Even if the SPE is only partially full, the entire 
SPE frame size is transmitted. If a node B has IP packets to send, 
the node cannot use the partially filled SONET frame received from 
the node A to add POS packets, because the PSL value identifies 
ftp only one type of data (ATM cells, in this example) . The node must 

; is: 

Ql now wait 125US for the partially filled packet to transfer down the 

Q link 32b- 32n. Furthermore, the SONET ring 3 0 cannot handle Tl or 

S T3 channels entirely in a payload space. The only way it can 

3 S 

flJ simultaneously support T1/T3 channels is by using virtual 
is tributaries and by using some of the tributaries for non-Tl/T3 
traffic. 

Statistically, a significant percentage of network 
traffic comprises IP packets that are quite small in size. Because 
higher-speed concatenated SONET frames are large in size, many 
20 times a SONET SPE may not be completely filled with packets or 
cells at the origin. Because a SONET SPE carries only one type of 
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data, the originating SONET node or other nodes downstream will not 
be able to add any different type of data to the SPE, and the SONET 
frame may be heavily underutilized. Such an under-utilization of 
the SONET frame degrades the overall bandwidth utilization of fiber 
capacity with SONET/SDH. 

7 

Referring to FIG. §, a system 50 is shown implementing 

A 

multiple fiber optic networks. The system 50 is shown implementing 
a Tl network 52, an ATM network 54 and a POS network 56. Referring 
to FIG. -4-, timing diagram illustrating transfer times of the 

1 

multiple data types of FIG. f is shown. Separate fiber networks 
for data types with current SONET protocols and separate fiber 
links are needed for transporting ATM, PDH traffic and 
variable-length packets such as IP or POS. PDH channels are 
created by strict timing relationships between consecutive 
Synchronous Transport Signal, Level 1 (STS-1) frames (to form a 
super frame) . Any intervening STS-1 frames containing ATM or POS 
packets will violate such timing specifications. 

Various conventional protocols have been developed to 
improve bandwidth usage by attempting to partially solve two 
problems in SONET networking (i) lack of support for data mixing, 
and (ii) bandwidth reuse limitations. Such conventional protocols 
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have been partially able to achieve additional bandwidth either by 
creating fatter pipes with VT, by filling payload with ATM cells 
0^ carrying different types of data, or by using^ SONET link as a 

multi-node access network using Ethernet framing for data packets. 
5 While virtual tributaries provide an efficient way to 

transport PDH traffic, allocation of bandwidth for LAN data such as 
10/100$tobs using a SONET fiber containing Tl traffic becomes 

A 

difficult. To support 10Mbps through Virtual tributaries one has 

0 to either dedicate an entire STS-1 (51Mbps) frame, or use several 
Wp virtual tributary channels and to perform inverse multiplexing. 

Virtual concatenation concatenates several VT channels 
S? into bigger virtual pipes to carry higher bandwidth traffic. With 

r% such a protocol, while some virtual tributaries carry T1/T3 data as 

1 : | 

flj usual, others are concatenated for transport of higher bandwidth 
□5 data traffic such as 10/l00Mbps links. 

However, virtual concatenation allocates a fixed 
bandwidth for LAN. Virtual tributaries cannot dynamically adjust 
bandwidth usage on a packet -by-packet basis. While it is possible 
to change the concatenated bandwidth through software, such an 
20 implementation does not yield much for bandwidth utilization. 
Bursty LAN traffic bandwidth usage is typically quite low, 
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resulting in significant waste when used over a fixed bandwidth 
virtual pipe (average use of a 10Mbps link is 20%, and if an entire 
STS-1 is used the efficiency becomes about 4%) . Another problem 
with virtual concatenation is that while one virtual pipe may be 
overloaded with traffic, others may be underutilized. Virtual 
concatenation cannot dynamically adjust network loads on different 
channels . 

Another conventional approach to increase* the utilization 
of SONET bandwidth is to fill the payload area with ATM cells using 



ap a technique known as ATM VP (Virtual Path) multiplexing. ATM VP 



multiplexing encodes packets in ATM cells and then inserts the 
U cells inside a SONET SPE. The ATM VP multiLplai&a r typically 

A 

Q utilizes CES to carry DS0/1 PDH traffic. 

^ However, operations, administration and maintenance (OAM) 

..S5S, 

JtS operations of ATM networks are different from that of SONET, and 
management of the two protocols can become difficult. Similarly, 
ATM network routing and switch-to-switch signaling data paths are 
different from IP network routes, resulting in network operational 
complexity. 

20 Network traffic statistics monitoring has shown that a 

significant percentage (about 45%) of network traffic comprises IP 
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packets with small packet sizes (e.g., around 40 bytes). With IP 
over ATM (rfc2684 - Multiprotocol Encapsulation over ATM AAL5) 
payload size slightly exceeds what can fit inside a single ATM 
cell. Such an arrangement results in transmission of two ATM 
cells, with the second cell that is mostly ATM overhead and 
stuffing bytes. This, with other ATM overheads, means having to 
allocate extra SONET bandwidth for IP transport if ATM is used as 
a transport protocol . 

In addition, using ATM for sending different services 
requires implementation of ATM transport protocols and interworking 
for all related protocols (such as IP-over-ATM, Frame Relay-ATM 
Internetworking, circuit emulation, etc.) in the device. Such 
implementation requires a high level of complexity in hardware and 
software, resulting in higher costs of manufacturing and operation 
of networks . 

Such conventional network architectures are not efficient 
for transmitting variable-length IP packets that form the majority 
of data network traffic on the Internet. Data network traffic 
comprises variable-length IP packets and fixed-length ATM cells 
(i.e., 53 bytes) . 
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As more and more data is being transported on SONET/SDH 
rings, there is a need to send variable -length packets on 
pre-existing SONET/SDH networks. These packets originate out of 
routers and other data access devices. While SONET/SDH networks 
must transport these data packets, they must also continue to 
support TDM-style fixed length packets for telephony and leased 
line applications. 

Conventional approaches cannot mix POS with ATM cells in 
a single SONET SPE. Conventional approaches do not leave some. area 
of the SONET SPE reserved for VTs and others for POS and/or ATM 
cells . 

Limitations of conventional approaches include one or 
more of the following (i) inability to mix TDM channels with 
packet -oriented data over SONET/SDH rings due to timing constraints 
of the TDM channels without a fixed bandwidth virtual tributary 
mechanism and (ii) limiting data channels sent on fiber carrying Tl 
lines to Virtual tributaries (since virtual tributaries are of 
fixed bandwidth, this restriction limits data channels to fixed 
bandwidth operation) . 

Therefore, if a SONET SPE is carrying all ATM cells, it 
cannot carry IP variable-length packets, and vice versa. Such 
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switches route all packets coming at one tributary to another until 
switching paths are changed through reprogramming . 

Conventional approaches do not take into account network 
loading conditions and do not support dynamic bandwidth 
provisioning. Conventional approaches also have increased traffic 
on core links from too much concentration into too few links. 
Transporting IP traffic over virtual tributary channels that was 
originally designed for DSO/l/3 connectivity is inefficient. 
Because VT assignment is fixed, IP transport is not able to take 
Jjjo advantage of total available SONET/SDH bandwidth. 

g3 In conventional approaches, IP packets are constrained to 

ri go through some pre -configured VT channels while other VT channels 
O may be under-utilized. Once a VT channel is dedicated for a 
nJ particular traffic and is put on a specific circuit-switched path, 

2^5 the topology does not change, even if traffic conditions change. 

Conventional approaches have the following disadvantages 
(i) ATM and Packets are implemented on different rings because of 
QoS and timing issues; (ii) very high cost for new fiber and SONET 
equipment for Telco/lSP/MAN; (iii) only one type of packet goes 
inside a SONET SPE at one time (the remaining bytes of f - ramo - o r 
SONET are wasted) (SONET packets go around the entire SONET ring, 
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limiting bandwidth) ; and/or (iv) the only way to support telephony 
channels along with data packets is to allocated part of SONET 
frame for packet data transmissions (which results in an 
inefficient bandwidth usage) . 

Summary of the Invention 

One aspect of the present invention concerns a frame 
configured to (i) be transmitted on a network and (ii) store data 
packets in a plurality of channels. One or more of the plurality 
of channels may be configured to store one or more fragments of the 
data packets. 

Another aspect of the present invention comprises an 
apparatus comprising one or more nodes coupled to a network. Each 
node may be configured to receive and/or transmit one or more of a 
plurality of frames. Each of the plurality of frames may be 
configured to store data packets in a plurality of channels. One 
or more of the channels may be configured to store one or more 
fragments of the data packets separated by an offset pointer. 

The objects, features and advantages of the present 
invention include providing a method and/or architecture that may 
(i) provide a single SONET ring to carry a number of forms of data; 
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(ii) allow a number of forms of data types to operate inside a 
single SONET SPE; (iii) permit filling of a fixed size payload area 
of a SONET/SDH network with data packets along with fixed bandwidth 
channels, (iv) allow fine-tuning of the available bandwidth of 
SONET/SDH to get exactly the T1/T3 bandwidth (or a fraction 
thereof, down to DSO bandwidth of 64kbps) required while using all 
of the remaining bandwidth for data packets, (v) provide bandwidth 
reuse at various nodes of a network; (vi) allow SONET sub-sections 
to run at full speed, effectively boosting SONET bandwidth; and/or 
(vii) provide a significant savings in equipment and fiber optic 
infrastructures . 

Brief Description of the Drawings 

These and other objects, features and advantages of the 
present invention will be apparent from the following detailed 
description and the appended claims and drawings in which: 

FIG. 1 is a detailed block diagram of conventional fiber 
optics transmission data types; 

FIG. 2 is a block diagram illustrating conventional 
transportation of higher bandwidth data packets; 
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FIG. 3 is a block diagram illustrating conventional 
transportation of higher bandwidth data packets; 

FIG. 4 is a block diagram illustrating inverse 
multiplexing for transporting higher bandwidth data packets; 
5 FIG. 5 is a block diagram illustrating conventional 

transportation of higher bandwidth data packets; 



FIG. 6 is a more detailed block diagram of the circuit of 



FIG. 4; 




FIG. 7 is a block diagram of a HDT £xa mg""- iiibidtr , a SONE T 



fflO^ -&PS; 

m 



FIG. 8 is a detailed block diagram illustrating a 



conventional timing operation; 



FIG. 9 is a block diagram of a preferred embodiment of 



the present invention; 



£5 



FIG. 10 is a more detailed block diagram of the circuit 



of FIG. 9; 



FIG. 11 is a block diagram of a HDT frame inside a SONET 



SPE; 



FIG. 12 is a block diagram illustrating transportation of 
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higher bandwidth data packets; 
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FIG. 13 is a detailed block diagram of an operation of 
the present invention; 

FIG. 14 is a detailed block diagram of a variable length 

envelope ; 

5 FIG. 15 is a block diagram of a packet of FIG. 11; 

FIG. 16 is a more detailed block diagram of a header of 

FIG. 9; 

FIG. 17 is a flow chart illustrating an operation of the 

■sF* 

~: present invention; 

IjjO FIG. 18 is a flow chart illustrating an operation of the 

present invention; 

• f * 

q FIG. 19 is a flow chart illustrating an operation of the 

■'X 

O present invention; 

Hj FIG. 20 is a block diagram illustrating an implementation 

|6 of the present invention; and 

'ICS 1 

FIG. 21 is a block diagram illustrating an operation of 
the present invention. 

Detailed Description of the Preferred Embodiments 

2 0 The present invention may provide a Hybrid Data Transport 

(HDT) protocol that may allow transmission of fixed bandwidth 
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channels (e.g., T1/T3) , variable-bandwidth data sources -(e.g., 
ATM) , IP and any other protocol data in a single SONET frame using 
a single fiber network. The protocol of the present invention may 
work seamlessly across a mix of SONET and non- SONET networks, and 
may yield cost savings in fiber infrastructure, equipment, and 
operation. 

With the use of the Hybrid Data Transport (HDT) protocol 
of the present invention, an existing fiber network may be fully 
utilized to transport a number of different types of traffic. The 
present invention may additionally dynamically manage bandwidth 
usage on a packet -by-packet basis. 

The present invention may provide spatial reuse of 
bandwidth, allocation of PDH bandwidth in 64Kbps increments, 
protocol -independent MPLS (Multi -Protocol Label Switching) support, 
and/or seamless operation over point-to-point and ring networks 
with SONET/SDH, direct data-over-fiber configurations or other 
network configurations. The present invention may also be 
applicable to Synchronous Digital Hierarchy (SDH) . However, SONET 
is used as a general description for SONET/SDH networks with 
similar implementation for SDH networks. Additional details of the 
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operation of the HDT protocol are also described in connection with 
direct data-over-fiber networks. 

1 

Referring to FIG.^1£, a block diagram of a system 100 is 

shown in accordance with a preferred embodiment of the present 

invention. A more detailed implementation of the system 100 is 

1° 

illustrated in FIG. The system 100 may comprise a number of 

* 10 

devices 102a-102n connected to a network backbone 104. FIG. %- 

A 

illustrates the addition of a number of chips 106a-106n. The 
devices 102a- 102n may receive T1/T3 signals, ATM signals, and POS 
signals. The devices 102a- 102n may receive data in one or more of 
the following data transmission media: SONET, SDH, direct data over 
fiber (e.g., both in point-to-point or ring configuration) with or 
without SONET/SDH framing and other transmission methods needed to 
meet the design criteria of a particular implementation. 

The system 100 may provide an increase in the data 
traffic handling capabilities of SONET/SDH networks. The system 
100 may implement a design of a SONET/SDH add/drop multiplexer 
(ADM) (and a SONET/ SDH cross -connect) that may function on 
variable -length packets. With such an approach, IP (or other 
protocol) packets of different lengths may be (i) added to a 
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SONET/SDH SPE and (ii) terminated at a different network node 
(e.g., devices 102a-102n) . 

Referring to FIG. ^, a detailed block diagram of 
SONET/ SDH payload envelope (SPE) 200 is shown. The present 
invention may embed a header (and/or footer) 202 (e.g., a 32-bit 
packet header) to create a deterministic packet transport protocol. 
The packet header may comprise a 32-bit payload header 204a-204n 
that may precede each frame, regardless of the particular packet 
type stored within the frame. The protocol identification may be 
implemented as a few header bits configured to denote the 
particular type of packet (e.g., ATM, IP, PPP, Frame Relay, etc.) 
embedded within the payload portion of a particular frame. 
Bandwidth maximization may be implemented with another bit in the 
header 2 02 that may specify whether the packet may be reused by the 
intermediate SONET nodes 102a-102n. The SONET framing may be left 
unchanged by implementing a single PSL (Path Signal Label) value 
206 in a SONET Path Over Head (POH) 208 that is generally able to 
specify the various types of packets embedded within the payload of 
a particular frame. The system 100 may be directly applicable to 
WDM /DWDM Fiber because individual packet framing is independent of 
SONET. The system 100 may be also used in IP-over-Fiber networks. 
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Referring to FIG.^$, a more detailed example of the frame 
200 is shown illustrating packet fragmentation across fixed 
bandwidth channels in accordance with the present invention. The 
frame 2 00 leverages the fact that SONET/SDH frames are normally 
synchronous in nature and that frame bytes are normally transferred 
in a single sequence within a timed window. 

An optical node may receive bytes from a synchronous 
frame (e.g., the frame 200) and generally fe&s access to all the 
bytes in the particular SONET/SDH frame. The particular frame is 
generally of a fixed size (e.g., for a given SONET/SDH speed and 
type) . The frames may be clearly marked and are normally 
accessible in a definitive manner using path overhead and line 
overhead markers . 

Instead of creating fixed bandwidth pipes by using 
virtual concatenation or implementing fixed-bandwidth inverse 
multiplexing pipes (as in conventional approaches) , the system 100 
may have different types of packets to span over available spaces 
inside particular SONET/SDH frame. The system 100 may provide an 
encapsulation 210 around the payload 212 that generally contains 
additional information about the packet. 
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Available space may be filled in with data packets as 
usual. When a particular packet cannot be placed fully in the 
available space (e.g., because of an impending fixed bandwidth 
channel) the particular packet may be fragmented and may be 
continued in the next available space. A packet (or a packet 
fragment) generally contains an offset (to be described in more 
detail in connection with FIG. 9) that may point to the beginning 

A 

of the next frame where the remainder of the packet is stored. The 
offset may be implemented, in one example, as a 32 -bit offset field 
at the end of the packet. The offset may mark the particular 
location where the packet is continued after the current end of 
frame . 

Depending on available space, a particular frame may be 
complete inside a SONET payload comprising outside framing bytes. 
In traditional internet protocol framing, any fragmentation may 
require each fragment to carry most of the IP header bytes with 
sequencing information. The sequence information allows the 
fragments to be reassembled. 

Internet protocol may allow ^-^lai^of f set value to link 
the next packet fragment to the previous packet fragment within the 
frame. The continuing packet fragment (s) do not generally need 
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internal header data repeated since thg^packet fragment (s) reside 
in a single SONET/SDH frame ^>00 and are transmitted in sequence 
within a synchronous^frc 

Rege^^ing-U LO FIG. 9 f an M^ajnpJ-g — ©f — an of -f-s^lrHfcoegtT 
operation 23 0 for a next packet fragment location i^^-Sliown. An 
offset pointer 232 may point to a header location 234 in the frame 
where the next portion of the packet is^uored. A packet may have 
a number of offset pointers if the'packet is stored in a number of 
locations. By breaking pap^ets into fragments, the frame 200 may 
be fully loaded prior^X) transmit. The frame 200 generally works 
with packets, ra^Her than frame divisions, and may fully utilize 
available bandwidth. The frame 200 may provide dynamic allocation 
of data/jackets inside SONET/SDH payload for maximum efficiency. 
Particular packet encapsulation may include details from HDT 
and may show the ottset word at the end~"""oT~~frame . 

The frame 200 may^permit filling of a fixed size payload 
area of SONET/SDH with data packers along with fixed bandwidth 
channels such as T1/T3. The frame 100 ma^reduce and/or eliminate 
bandwidth limitations imposed on data packets lfi^ixed bandwidth 
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The frame 200 may provide a savings in equipment and 
fiber optic infrastructures. The frame 200 may permit fine-tuning 
of the available bandwidth of SONET/ SDH to provide the bandwidth 
required for T1/T3 while using the remaining bandwidth for data 
packets without requiring complex inverse multiplexing or virtual 
concatenation techniques. 

The frame 2 00 may provide advantages that may (i) permit 
filling of a fixed size payload area of a SONET/ SDH network with 
data packets along with fixed bandwidth channels, (ii) allow fine- 
tuning of the available bandwidth of SONET/SDH to get exactly the 
T1/T3 bandwidth required while using all of the remaining bandwidth 
for data packets, and/or (iii) provide a significant savings in 
equipment and fiber optic infrastructures. 

a 

Referring to FIG. ^2, an example of the SONET/SDH payload 
envelope 200 (e .g . /Ntransmitted every 125p.S) divided into variable 
length packets is shownX The header 202 may comprise one or more 
of the following parameters :\(i) packet length, (ii) length of CRC 
(Cyclic Redundancy Check) , (iiri payload identifier header to 
describe the nature of packet, (iv)N^oute labels that may help 
route packet inside network, (v) payload reader CRC, (vi) actual 
payload, — a nd/or — fvi^r) — payloa ds— €R€-: 
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In SONET, a basic unit of transmission is a Synchronous 
Transport Signal Level 1 (STS-1) or Optical Carrier Level 1 (OC1) 
signal. Both operate at 51.84 Mbit/s. STS-1 describes electrical 
signals, and OC1 refers to the same traffic after being converted 
into optical signals. SONET also allows channels to be 
multiplexed. An OC12 circuit, for instance, may carry traffic from 
four 0C3 links. An OC12 circuit may also carry a single channel, 
in which case the line is said to be concatenated. Such circuits 
may be described as OC3c, OC12c, and so on. 

Another protocol similar to SONET is Synchronous Digital 
Hierarchy (SDH) , defined by the ITU (International 
Telecommunication Union) as G.707 (shortly after ANSI formally 
ratified the T.105 spec for SONET). Although interconnection of 
SONET and SDH networks may be relatively rare, several new 
transoceanic telecommunications projects make use of such links. 

The system 100 may maximize fiber bandwidth by 
implementing the Hybrid Data Transport (HDT) Protocol. The HDT 
protocol may allow dynamic management of packets to maximize 
bandwidth. The system 100 may allow the transport of different 
types of data over a single fiber link. With the system 100, IP 
(or other protocol) packets, Packet -Over- SONET (POS) , ATM cells, 
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G.702-based PDH (T1/T3) , SRP, Frame Relay, and other types of data 
may be mixed inside a SONET payload and dynamically and sent on a 
single fiber (as shown in FIGS. ^5* and ^6) . The system 100 may 
provide robust scrambling and unified packet transport over ring 
5 and point-to-point networks and may be well suited for non-SONET 
configurations such as point-to-point WDM networks. The SONET SPE 
2 00 may be filled with HDT frames that may carry a wide mix of 
fixed and variable bandwidth data. The Simple Data Link (SDL) 
CJ framing protocol prefixes a payload with a 32 -bit word, 16 bits of 

j4j0 which hold the length of the packet and the other 16 bits contain 
CRC (Cyclic Redundancy Check) for the length field. SDL may 
provide a robust CRC- 16 based framed boundary delineation mechanism 

■•c=;r 
a 

p compared to hybrid mix of point-to-point and ring topologies. 

fy The system 100 may implement a single fiber link that may 

■V. i 
-J 

S5 be used for sending different kinds of traffic to use the full 

€3 

capacity of the link. The system 100 may allow VT or sub-VT 
channels to be eliminated. ATM cells, IP (and other protocols) 
packets, PPP, frame relay, NxDSO, T1/T3 and others may be mixed 
^ inside .SPE on a packet -by-packet basis. 

y A T1/T3 

tr- 20 PDH channels (such as may be dynamically allocated 

\y ^ 

Qr^ anywhere inside^ SONET payload in 64Kbps bandwidth increments. 
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Bandwidth may be reusable in fine granularity in 64Kbps increments, 
with any type of data. For example, an IP packet may be dropped at 
a node (e.g., B) where the node B may reuse the packet area for 
inserting ATM cells, frame relay, PDH traffic, or any other data 
type . 

The system 100 may transport many packets of one or more 
different data types. The particular type of data may be placed 
inside a single SONET SPE or data-over- fiber frame while preserving 
time dependency of data packets, such as PDH. The system 100 may 
be implemented without terminating the whole link capacity at each 
node. Destination nodes may indicate a start of the packet inside 
a SONET payload. Other packets may pass through the node. 

Direct data-over-fiber configurations (e.g., without 
SONET framing) may be easily supported with full link monitoring 
and management. Support may also be provided for variable-size 
packet SONET add/drop multiplexer (SONET ADM) devices. 
Variable- size packets may be transported inside a SONET SPE and 
nodes may cross-connect and add/drop the packets on different 
ports . 

The system 100 may provide protocol -independent transport 
of MPLS labels. The HDT may provide for transmission of MPLS 
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labels outside of protocol frame (rather than embedding such labels 
between data link and network layers as in conventional 
approaches) . Intermediate SONET and optical fiber nodes may be 
used to create switching and add/drop systems without having to 
5 become protocol -aware . 

With provision for MPLS labels transported outside of 
packets, the HDT may allow setting up of fast-reroute 
fail -switchover paths over a hybrid of ring and point-to-point 
CJ networks using MPLS labels, without requiring nodes to be 

}1;0 protocol - sensitive . Such an implementation may eliminate the need 

5 1 i 
-e-rr 

■: I"* 

JJi to provision and reserve completely unused backup paths on SONET 
f ^ rings . 

Q In operation, the payload headers 204a-204n may precede 

D 

pj every packet to carry the information to support HDT. A uniform 
ffife structure of the header across a variety of packet types generally 
simplifies design of optical nodes for packet processing for both 
SONET and direct data-over-fiber networks. The headers 204a-204n 
may also contain a reusability bit that is set by the sending node. 
If the reusability bit is cleared, a destination node may reset the 
20 data identification bits to free up the packet area for reuse by 
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new data packet. The packet area may be reused at either at the 
destination node or other downstream nodes. 

/ S^^> By using the payload header 204a-204n to identify the 
type of a packet, the HDT is generally able to extend data 
5 identification beyond PSL-based SPE- level data typing and put 
multiple data types inside a SONET SPE. A value of 0000 may 
indicate the packet area (e.g., the length of the packet area is 
given by the length value in the outside SDL framing) that does not 

Q generally contain any useful data and can be reused for storing new 

. f •% 

ti]0 data. HDT may easily support traditional PDH and other guaranteed 

W 

^ bandwidth channels. In SONET networks, a frame repeats every 

m 



125yS, resulting in a bandwidth of 64KHz for every byte in the 
payload. By fixing the starting location of some packets inside 
the SONET frame, slots may be created for sending TDM- style 
ffS traffic. Because the packet length is changeable in one-byte 
increments, such slots may be created in increments of 64KHz. 
Because packets are dynamically created, fixed bandwidth channels 
may be created on the fly by clearing the reusability bit in the 
payload header. , 

A 

Referring to FIG.^, a detailed block diagram of the 
SONET SPE 2 00 is shown. The SONET SPE 2 00 may comprise a number of 
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packets 220a-220n and a number of empty packets 222a-222n. The 
packet payload header 2 04a of the packet 22 0a may identify the 
packet/protocol. The packet payload header 204a may identify a 
packet type of the packet 220a stored (or transported) . The 
payload header 204a may tell what kind of packet/protocol (such as 
Ethernet, PPP, IP, Frame Relay, ATM cells, Tl, etc.) is inside a 
payload of the packet 220a. Different protocols may be supported 
at two ends (e.g., the devices 102a-102n) of a network without the 
need for provisioning in advance. In contrast, conventional 
approaches use a protocol over WAN which is usually negotiated 
between two parties at the ends devices 102a- 102n of the WAN link. 

The payload header 2 04a may be used to tell whether one 
or more of the empty packets 222a-222n inside the SONET SPE 200 may 
be reused at an intermediate node. In contrast, in conventional 
SONET networks, the entire SONET SPE 2 00 travels around the ring 
until removed by the sender. With the system 100, a receiver may 
mark the SONET SPE 2 00 as reusable. Nodes on the fiber network 100 
may mark different sections of the SONET SPE 2 00 as reusable by the 
other nodes 102a-102n. 

Provisioning of TDM channels may provide the ability to 
mark a portion (or many portions) of a SONET SPE payload area as 
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non- reusable . With a non-reusable area, even when a receiver 
receives the packet, another receiver cannot reuse the packet area. 
However, the same receiver may reuse the non-reusable area. 

In general, there is no limit to the order and manner of 
packet positioning. Any packet may be marked in any fashion to 
support, for example, a dynamic mix of data and voice (TDM) traffic 
on a SONET/SDH network. Such an implementation is not possible 
with current technologies. The present invention may solve the 
problem of mixed value and data transmissions faced by telephone 
carriers and data providers. 

As SONET frames containing fixed bandwidth channels move 
around the ring, intermediate nodes may detect these packets (e.g., 
the reusability bit is reset) , note the offsets of these packets, 
and preserve the respective offsets when recreating the frame 
(e.g., after adding packets from local input ports) for outbound 
traffic . 

or 

Referring to FIG. ^9, a detailed example of a packet is 
shown. An SDL framing 262 may be in the first 16 bits and may 
contain the length of the entire payload, including SDL framing 
bytes. A 16 bits of CRC-16 2 64 may be provided on the length field 
(e.g., xl6 + xl2 + x5 + 1) . The payload header 204a-204n may be a 
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32 -bit word, followed optionally by an OAM bytes or MPLS labels 
268. MPLS/OAM bytes may be variable number of MPLS labels or OAM 
values that may be transmitted in the header area of HDT, outside 



of* payload. A next fragment offset 270 may be a 16-bit value 

showing the location offset of next packet fragment (if any) of the 

A 

packet. The next fragment offset 270 is generally taken from the 



start of^ current packet. A header CRC 272 may be computed over 
payload header bytes only, with same scrambling polynomial used for 
SDL framing. A payload area 274 may contain the actual packet to 
be transmitted over the WDM or SONET link. The payload area 274 
may contain one of a number of types of protocol packets, such as 
Ethernet, ATM, GR.702, PPP, Frame Relay, etc. A payload CRC 276 
may be user-controlled value and may be computed for the payload 
bytes only. The payload CRC 276 is generally either a 16 or 32 -bit 
value, depending on mutual negotiation between sending and 
receiving stations . 



header 204a are shown. The particular bit width of the payload 
header 2 04a may be varied accordingly to meet the design criteria 
of a particular implementation. A packet identifier 280 (e.g., D3 : 
DO) generally identifies the type of packet in the payload. For 
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various parameters of the packet 
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example, value of 0000 may represent a null packet. A null packet 
may indicate that the payload area may be reused. When a packet is 
dropped at a node, the length field does not generally need to be 
modified for the packet, only the D3 : DO bits need to be cleared. 

A header data area 282 may carry MPLS labels (e.g., 
outside of payload area) . Operation administration and maintenance 
(0AM) bytes 282 may be used for link management, or any other data 
separately from the payload. A reusability area 284 (e.g., D7) may 
be a "1" . If a SONET node can reuse a particular packet area, the 
size of the packet area may be given by the packet length field 2 64 
of the SDL header. If the bit D7 is set to a "0", then a node will 
not generally mark the packet area as re -usable, even after a 
packet has been dropped. The particular nodes of the various 
configuration bits may be varied (e.g., inverted) accordingly to 
meet the design criteria of a particular implementation. 

A header length area 286 (e.g., D15: D8) may include, in 
one example, a 32 -bit payload header. A fragment identifier area 
288 (e.g., D17: D16) may be implemented as a two word value. A 
value of "00" may indicate that the payload area contains a 
complete packet. A value of "01" may indicate the beginning packet 
of a fragmentation sequence. A value of "10" may indicate a 
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continuation of packets. A value of "11" may mark the last 
fragment in the series. Other particular bit patterns may be 
implemented accordingly to meet the design criteria of a particular 
implementation . 

A padding area 290 (e.g., D18: D19) may indicate a 
minimum packet length. In one example, the minimum packet length 
may be 4 bytes (e.g., 2 bytes length + 2 bytes CRC) . Idle bytes at 
the end of packets and elsewhere may be marked by a length field of 
"0000" . In instances there may be less than 4 bytes left between 
packets. In this case, it may be impossible to place a SDL null 
packet. Such idle bytes are shown as tail-end padding for the 
preceding packet. An unused area 292 (e.g., D31:20) may be used 
for additional expansion. 

n 

Referring to FIG. S, an example of a receive operation 

A 

is shown. A node may receive a frame at a block 300. A block 302 
may determine if the received frame is an HDT frame. The block 302 
may use the PSL value in the POH to determine the type of protocol 
carried inside the SPE. If the PSL shows POS, ATM, or PDH traffic, 
the receive operation may proceed to the block 304. If no HDT 
packets are present, a block 306 handles the POS/ATM/PDH packet. 
If in the block 3 02, the PSL shows the SPE contains HDT frames, the 
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node uses additional logic for HDT processing to detect and route 
different types of packets embedded in the SONET SPE 200. 

A block 308 may read the POH. A block 310 may determine 
a first packet of the SONET SPE 200. A block 312 may read a length 
5 and CRC of the first packet. A block 314 may determine a match of 
the length and the CRC. If a non-match of the length and CRC 
occurs, the receive operation is generally set to a block 316. The 
block 316 may read a next word of the packet from the SONET SPE 
Cj 318. If a match occurs, the receive operation may process the 
Sip packet. Once the payload header has been processed and different 
Xj packet types are been processed and different packet types are 
identified, hardware (e.g., implemented in the system 100) may use 
P header fields to retrieve the payload and use usual hardware blocks 

■ 3s ! 

Fy for processing. 

IS ATM cells are generally retrieved by first looking at the 

Q 

PSL value to determine their presence and then reaching the SONET 
SPE to get fixed byte ATM cells, either with or without HEC-based 
cell delineation. For example, if the payload header in the HDT 
shows the payload contains ATM cells, the hardware device generally 
20 retrieves payload bytes (up to number of bytes specified in length 
field) and sends the byte stream to an existing ATM cell processing 
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G 350, 352 and 354. HDT adds a header to packets to allow their 
fp mixing within the same SPE 200. Much of the HDT processing is 
generally related to processing of the header to identify the type 
of packet and then passing the starting address of data bytes to 
standard logic for handling the individual packet type. Support of 
f]j PDH-type channel typically requires a fixed starting location for 

£$ the channel in every frame. If PDH support is not needed, packets 

O 

of any mix may be put anywhere inside the SPE 2 00 to achieve 
excellent bandwidth utilization without much operational 
complexity. When fixed bandwidth channels are carried, some data 
packets may need to be fragmented when the packet hits a static 
20 location. Fragmentation of a packet, however, is generally easily 
achieved in SONET networking because all bytes in the SPE 2 00 are 
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logic. The ATM cell processing logic may then work on the byte 
stream using HEC hunting just as if the SPE contained only ATM 
cells in its payload. 

l4 

Referring to FIG. , an example of a processing 
operation 32 0 is shown. A device supporting Hybrid Data Transport 
HDT protocol generally operates much the same as a normal SONET/ SDH 
transport operates. Operations for processing ATM cells, POS, and 
PDH protocols are the same and illustrated as processing blocks 
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transmitted sequentially. Additionally, recovering fragments and 
putting the fragment together may be simply accomplished. 

Referring to FIG.^f3, an example of a transmit operation 
400 is shown. A device supporting HDT may receive a packet to be 
transmitted from a system side. In the transmit operation 400, a 
node may take inputs from different sources 402, encapsulate the 
packets with an SDL length/CRC fields 404, add an HDT header 406 to 
each of the packets, and then store the packets inside the SPE. 
The node may not send a fresh frame on the network in order to 
transmit the packets. A TDM channel check 408 may determine a 
reusability of the SPE 200. The transmit operation 400 may reuse 
available space in an incoming SPE (containing HDT frames) . The 
transmit operation 400 may then may proceed to a length check 410 
to see if there is any space available to insert the packet to be 
sent. If there is enough space, the entire packet is stored (with 
proper SDL framing and HDT header bytes) . Any remaining bytes, 
depending on the size, are generally either (i) filled with a null 
HDT packet (e.g. , the payload header identification bits are 0000) , 
(ii) filled with SDL null packets (e.g., pairs of length/CRC with 
a null length field) , or (iii) accounted for as tail-end padding 
(e.g., if the size is less than 4 bytes). 
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If the transmit operation 400 runs into a fixed-bandwidth 
channel allocation midway through the packet allocation, the packet 
is generally fragmented. In this case, a portion of the packet may 
be stored at one place and other fragments may be stored at another 
5 free location. The first fragment offset pointer may contain the 
starting location of second fragment. Because bytes are 
transmitted sequentially in the SPE 200, reassembling fragments may 
be easily achieved. 

Cf If a particular node detects an incoming SONET frame on 

ill 

tO a receive port, or if there is a frame in the transmit/receive 

1 El 

queue, the node checks the frame to see if there are 
p unused/reusable areas in the incoming/queued frame that can be used 

O for sending data. If there is enough space available in the frame, 

hi 

Hi the node fills the space with additional data before sending the 
\i 

|5 frame out . 

In HDT, PDH channels of any bandwidth (up to allowable 
SONET bandwidth limits) may be provisioned anywhere inside the 
SONET SPE. To achieve precise timing, PDH bytes must begin at the 
same offset inside the SONET SPE. However, allocation of PDH 

2 0 channels at different locations inside a SONET SPE may create 

fragments of unused bytes all over the SONET SPE. For efficient 
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transport of variable- size IP packets, these unused bytes may be 
utilized for IP data. 

Referring to FIG.^ift, an operation 500 for CRC error 
checking is shown. If bit errors occur at an upstream node that 
5 receives a packet with a correct CRC, the downstream node will 
never learn about the bit errors if the upstream node recomputed 
CRC for the packet before transmission. When MPLS is used, a node 
that receives the packet usually swaps the label with a different 
Cf value, pops the label, or adds a new label to the stack. If MPLS 
is embedded inside a packet, payload CRC will change at each node. 

One solution would be to check for CRC for ingress, but 
not to re-compute the CRC on egress. An efficient way to implement 
p such CRC computation is to separate header CRC from payload CRC. 

■1 - ! 

nj This way, header CRC is recomputed easily and quickly at 
£1 intermediate nodes while the payload CRC is preserved end-to-end. 
With HDT, all header labels and other temporary information for the 
packet may be carried outside of the payload so the payload 
data/CRC is not modified at any of the intermediate nodes. 

A SONET node may be a data-aware add/drop multiplexer, a 
20 digital cross-connect, or a router/access multiplexer sitting on a 
SONET ring. Such devices may implement HDT protocol for data 
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encapsulation and transport over SONET and WDM networks. 
Traditional circuitry for ATM cell delineation, PPP processing and 
other protocol handling may be implemented similar to conventional 
approaches, with some additional added circuitry for HDT 
encapsulation and decapsulation. The path signal label (PSL) value 
proposed for use with the HDT may be the same as the one for SDL 
frames . 

A\ 

Referring to FIG. ^±-5*, an example of spatial reuse with 



Q HDT is shown. Spatial reuse of bandwidth across a number of 
M® network nodes (e.g., A, B, C, D) may be achieved by permitting full 
'f2 or partial termination of individual packets at any node. Spatial 
reuse of bandwidth reclaimed from the* terminated packet may 

■n 

p increase performance. HDT may provide an ideal way to achieve 

m spatial reuse of SONET bandwidth. Using add/drop of hybrid data, 

\l 

3gS nodes can reuse released bandwidth for transmission of any of the 

Q 

various kinds of data. 

As the SONET SPEs are received at the nodes A, B, C, D, 
initial bytes may be placed in a small transit buffer. Through 
MPLS labels contained in the header section or through internal 
20 packet fields, a particular node A, B, C, D may be able to 
determine whether the packet belongs to the node. If the packet 
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does not belong to the node, the bytes are streamed out of transit 
buffer to the output port. However, the packet may belong to the 
node A, B, C, D if, for example, (i) the D7 bit is set in the 
payload header, (ii) the packet area has been reserved for a fixed 
bandwidth channel such as a PDH, and/or (iii) in this case, the D3 : 
DO bits are not cleared. If the D7 bit is set to "0", the node may 
clear the D3 : DO field to mark the packets void and reusable, where 
the bytes belonging to the packet are sent to system. The number 
of bytes sent to the system may be specified in the length field of 
the SDL header. If the header shows fragmentation then a packet is 
received in many fragments and sent out to the system until the 
last fragment is received. 

Packets may be added either using a fresh SONET SPE or by 
reusing bytes inside an incoming or previously queued frame. The 
decision of which packet to add to a void or reusable packet area 
inside an SPE can be made on following lines by (a) selecting a 
packet (or a collection of packets) that will fit inside the 
reusable area, (b) selecting all packets that can fit inside the 
reusable space, or (c) selecting a packet based on QoS parameters 
or packet priority. Since SONET frames repeat at 125ms intervals, 
packet transmission may be arranged to achieve a desired rate. 
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Once a packet is selected for addition to the SPE, the node creates 
a payload header by setting payload type, reusability and other 
bits for the packet. The circuit 100 may then add the header to 
the payload. 

The SDL framing mechanism may use length/CRC pair 
information as a header and a frame delimiter. SDL provides a 
robust scrambling and frame locator technique and may be used for 
direct data-over- fiber networks where SONET framing may not be 
used. Implementing OAM packets may eliminate the need for complex 
SONET framing and link management overheads. In the example of 
direct data-over- fiber networks, the HDT protocol structure may 
operate unmodified. Point-to-point WDM networks and ring-based 
SONET networks (or any other network) may easily be mixed and 
connected to each other. With a powerful support for MPLS (that 
may be transported independently of payload) , networks may be 
designed that may have alternative LSP (Label Switched Paths) links 
for a highly robust redundancy. For example, nodes on a SONET ring 
may be connected through another network that may be entirely 
different from the ring. The backup path could be a high-speed 
point-to-point link or a ring network that may be geographically 
quite diverse. By providing a common network protocol engine, the 
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HDT protocol may permit configuration of these networks quite 
easily without requiring complex protocol translation logic for 
different network configuration. 

The present invention may use a packet payload header to 
5 identify the kind of packet inside. These identifier bits tell 
what kind of packet/protocol (e.g., such as Ethernet, PPP, IP, 
Frame Relay, ATM cells, Tl, etc.) is inside the payload. Using 
such a technique, different protocols may be supported at two ends 
^? without the need for advanced provisioning. Using conventional 
£d methods, the use of a single protocol over a WAN needs to be 
m negotiated. 

O The identifier may indicate whether one or more packet 

£2 areas inside SONET SPE may be reused at an intermediate node. 

y 

■[*-* Conventional SONET networks require the SONET frame to travel 
|3 around the ring until removed by the sender. Even when the 
receiving node received a packet, the frame went around the 
network, wasting bandwidth. With the present invention, not only 
may a receiver mark a SONET SPE as reusable, but different 
receivers on the fiber network may mark different sections of SONET 
2 0 SPE area as reusable when a packet is received by different 
receivers . 
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The present invention may provide the ability to mark a 
portion (or many portions) of a SONET SPE payload area as 
non-reusable. With such an implementation, when a receiver 
receives the packet, the packet area is not generally reused by 
another receiver/ transmit ter . However, the same receiver may reuse 
the marked payload area for add/drop applications. Allowing the 
same receiver to re-use a packet may help TDM channels and packet 
data within a single SPE. 

Over time, bit definitions inside a payload header may 
change as further research is conducted on the fiber data protocol 
operation. Such changes in bit definitions are common in data 
communication protocols and do not change the nature and content of 
present invention. 

The present invention often refers specifically to SONET. 
However, Synchronous Digital Hierarchy (SDH) protocols are equally 
appropriate. SDH is similar to SONET with differences in bit 
framing. These framing differences, however, do not change the 
discussion and scope of the present invention. 

While the invention has been particularly shown and 
described with reference to the preferred embodiments thereof, it 
will be understood by those skilled in the art that various changes 
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in form and details may be made without departing from the spirit 
and scope of the invention. 
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